Distributed system for multi-function secure verifiable signer authentication

ABSTRACT

A distributed multi-function secure system for verifiable signer authentication having a personal private key stored in a secure storage of a mobile device where the mobile device connects to a fragmented distributed signing engine by a secure protocol and is issued a signer certificate from a circle of trust certificate server to securely electronically sign documents.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. ProvisionalApplication No. 61/165,014, filed on Mar. 31, 2009, in the United StatesPatent and Trademark Office.

FIELD

The field of this intervention relates to signature pads and moreparticularly, a distributed system for multi-function secure verifiablesigner authentication that is secure, highly available and inexpensive.

BACKGROUND

Signing is a human activity that has evolved over time from a rigid,behind closed doors activity, to an online Web based experience.Barriers of space and time, i.e., all signers must be present at thesame place and at the same time, have been broken to reflect our new wayof interacting with one another in a fast paced global village. Evenwhat we are signing is no longer restricted to paper documents.

The majority of the tools on the market today do not allow signers todigitally sign their documents. Instead, the tools themselves sign thedocuments on behalf of the signers. In practice, the tools use a singleprivate key that belongs to the owner of the tool and sign all documentswith it. The signer provides only his signature image. In the case of“signing as a service” where the signing engine resides somewhere on theWeb and signers upload their documents and sign them online, not onlyall documents are signed using the private key of the Web site butsigners are not even allowed to provide their signature images. Clearlythese signing tools have lost their objectivity and instead of being athird party to the transaction they have become a participant.

Referring now to FIG. 1, there is shown a diagram a prior art locationspecific secure signature authentication system 100 currently used. Ascan be seen, traditional signing engines 100 require that all thesigning activities take place in the same hardware. The document to besigned, the certificates to sign with, the clock to provide thetimestamp, and the location info (i.e., hardware info) 104 are allpresent in the same hardware configuration and there is no need for anydata to travel on networks. A traditional signing engine performs thethree standard digital signature operations in the same physicalhardware: the signing server. All documents are signed by the “servercertificate” 106 and all digital signatures produced 108 are identical.The signer's credentials are ignored and never used.

As can be seen, the signature pads that are presently used, will not beable to fulfill these requirements.

Therefore, there is a need for a distributed system for multi-functionsecure verifiable signer authentication that is secure, highly availableand inexpensive.

SUMMARY

The present invention meets this need by providing a system designed tosatisfy the deficiencies in the current art namely: mobility, signerauthentication, agility, always on, online, and security for mustprovide signer credentials for authentication, secure access to the Web,secure transmission of data, secure local storage, and its owncredentials for device authentication. The invention comprises adistributed system for multi-function secure verifiable signerauthentication having a) a personal private key; b) a mobile device forstoring the personal private key, where the mobile device furthercomprises a secure local storage; c) a fragmented distributed signingengine communicatively coupled to the mobile device; d) a secureprotocol communicatively coupled to both the mobile device and thefragmented signing engine; e) a circle of trust certificate servercommunicatively coupled to the mobile device; and f) a signercertificate communicatively coupled to the mobile device, the circle oftrust certificate server and the fragmented distributed signing engine.

Additionally, the personal private key is a private key issued by thecircle of trust certificate server. The signer certificate comprises thedocument, a time, a place and signer credentials in a single encryptedstructure. The mobile device is configured for secure wireless Internetaccess and is selected from the group consisting of a cellular phone, acomputer, a wireless PDA, a smartcard, an ATM keypad, a magstripe readerand a smartcard reader. The fragmented distributed signing engine isconfigured to hash and prepare a document for authenticated digitalsigning. The mobile device is configured to sign with the personalprivate key of the signer and send the resulting digital signature backto the server to be embedded into the document. The protocol isconfigured to securely transmit at least part of a complete securelysigned document to the fragmented distributed signing engine, from thefragmented distributed signing engine or both to and from the fragmenteddistributed signing engine. The protocol is also configured to securelytransmit at least part of a complete securely signed document to themobile device, from the mobile device or both to and from the mobiledevice. Also, the protocol means for secure transmission between themobile device and the fragmented distributed signing engine isdistributed. The circle of trust certificate comprises a public key andinformation about the user and the signer certificate is unique to eachsigner to each circle of trust certificate.

There is also provided a method for a distributed system formulti-function secure verifiable signer authentication comprising thesteps of: a) providing the system of claim 1; b) joining a circle oftrust; c) obtaining a personal private key; d) providing a document tobe securely signed from a fragmented distributed signing engine; e)signing the provided document using the personal private key; f)recombining the provided document and the personal private key by thefragmented signing engine; and g) transmitting the recombined documentto a destination. The step of joining a circle of trust furthercomprises protocol means for securely transmitting information betweenthe mobile device and the fragmented distributed signing engine. Thestep of obtaining a personal private key is performed by the circle oftrust server using a user's profile information and a unique deviceidentification. The circle of trust server combines the user's profileinformation and the unique device identification into a unique userreference number for a particular circle of trust. The user's profileinformation, unique device identification and unique user referencenumber are stored on the circle of trust server for securely verifyingthe mobile device. The step of recombining the provided documentincludes transmitting a challenge and receiving a response from themobile device. The challenge and response use the private key of thedevice and no server certificates.

A method for a protocol for a distributed system for multi-functionsecure verifiable signer authentication is also provided comprising thesteps of: a) initialization of the mobile device; b) enrolling a mobiledevice to a secure server; and b) authenticating the mobile device tothe secure server. The step of initialization further comprises thesteps of: a) acquiring an application comprising the protocol; b)starting the application; c) generating a public key and a private keybased on PKI technology and the user's information; d) storing thepublic key and the private key in the mobile device; and e) generating atemporary unique hash from the user's name and a unique deviceidentification. The step of enrolling further comprises the steps of: a)providing a profile to the circle of trust server; b) generating aunique user reference number from the provided information; c)displaying the unique user reference number; d) selecting a circle oftrust server from a displayed list on the mobile device; e) entering theunique user reference number; f) registering the mobile device with thecircle of trust server; g) verifying the signer certificate; h)combining the unique user reference number and the unique deviceidentification and the public key; i) transmitting data bidirectionallywith the circle of trust server using the combination of step h); j)decrypting at the circle of trust server the data; k) storing on thecircle of trust server the unique user reference number and the uniquedevice identification in the profile; 1) producing a signer certificate;m) transmitting the signer certificate to the mobile device; and n)storing the signer certificate in the local secure storage on the mobiledevice. The unique user reference number is transmitted to the user byemail. The step of authenticating further comprises the steps of: a)executing an application comprising the protocol; b) downloading acircle of trust server list; c) displaying the list on the mobiledevice; d) selecting a circle of trust server from the displayed list;e) connecting to the selected circle of trust server; f) verifying asigner certificate stored in the mobile device; g) retrieving theprofile associated with the signer certificate; h) generating achallenge to the mobile device using the public key stored in theprofile; i) transmitting the challenge to the mobile device; j)decrypting on the mobile device the challenge using the private keystored in the local secure storage; k) combining the challenge and theunique device identification; l) generating a hash from the combinationin step k); m) encrypting the hash with the public key received from thecircle of trust server to produce a response to the challenge; n) sendthe response to the circle of trust server; o) decrypting the responseusing a server private key to extract the response and the unique deviceidentification; p) verifying the challenge and the response; q)providing a secure channel between the mobile device and the circle oftrust server if the challenge and response are verified; and r)transmitting signature data.

A method is provided for obtaining an electronic signature by a)receiving at a document server a request for a document to be signed; b)providing the requested document for receipt by a mobile device; and c)receiving the signed document from the mobile device with a signercertificate, the signer certificate being unique for the mobile deviceand the document, the certificate having been provided to the mobiledevice by an authentication server physically separate from the documentserver. In one embodiment, second server is remote from the firstserver.

A method if provided for authenticating an electronic signature for adocument comprising a) storing personal private key for use with aunique mobile device and personal information associated with a user ofthe mobile device; b) receiving a request to certify the user at anauthentication server, the request including the personal private key, aunique identifier for the mobile device, and information relating to thedocument, the information relating to the document and the documenthaving been provided by a document server separate from theauthentication server; and c) providing to the mobile device a signercertificate for the certified user, the signer certificate being uniquefor the mobile device and the document, the signer certificate beingreadable by the document server. In one embodiment, the personal privatekey provided is for use with the unique mobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects and advantages of the presentinvention will become better understood with regard to the followingdescription, appended claims, and accompanying figure where:

FIG. 1 is a diagram of a prior art location specific secure signatureauthentication system;

FIG. 2 is a diagram of a distributed system for multi-function secureverifiable signer authentication according to one embodiment of thepresent invention;

FIG. 3 is a chart of the strength of admissibility of various signatureauthentication techniques;

FIG. 4 is a detailed diagram of the system of FIG. 2 according to oneembodiment;

FIG. 5 is a chart of a protocol method for initialization of the systemof FIG. 2 according to one embodiment;

FIG. 6 is a chart of a protocol method for enrollment in the system ofFIG. 2 according to one embodiment;

FIG. 7 is a chart of a protocol method for authentication for the systemof FIG. 2 according to one embodiment; and

FIG. 8 is a diagram representing circles of trust useful for the systemof FIG. 2.

DETAILED DESCRIPTION

The present invention solves the problems that stem from the fact that asingle private key is being used to sign all documents. The presentinvention allows each signer to use their own private key to sign. Thisimplies local signing, i.e., signing that must take place at the clientsite and not at the server site. Consequently, the signing engine mustbe able to function partially on the server to hash and prepare thedocument, and partially on the client to sign with the private key ofthe signer and send the resulting digital signature back to the serverto embed it into the document. This novel fragmented signing engine andthe new protocol used to secure the exchanges between server and clientin one embodiment of the present invention. This distributed signingengine provides mobility and allows a user to sign anywhere.

As a user exists in the physical world and the user's certificaterepresents him in the cyber world. Using the secure protocol presentedherein provides user/signer authentication that can be added naturallyby using the existing PKI infrastructure of the client and of the serverto provide mutual authentication. The present invention has thepotential to become an extension of the signer, a trusted signing token,and allow real globalization of authenticated digital signing.

The platform described herein is a software platform for smart phones,iPhones, PDAs, tablet-PCs etc. The platform will be able to run onWindows XP and VISTA, Mac OS, Linux and Blackberry (Java) as well asother future signing pads. The platform of the present invention takesadvantage of the PKI capabilities of the underlying operating system tocommunicate securely with a server.

Being in the palm of a user's hand will allow signers who possess adevice with the present invention to be called (or invited) to signsecurely and safely, regardless of their physical or cyber location. Nolonger will the signer's physical presence be needed in order to obtainhis signature (both digital and squiggle).

Mobility (freedom from geographical restrictions), agility (freedom fromform factor), always on (freedom from wires), online (freedom to choosetype of signature), and security (freedom from fraud), are some of therequirements of the future signer that are met using the presentinvention.

Additionally, signers are not the only ones changing. Governments andinstitutions are also changing their requirements to includeglobalization, signer identification, i.e., authentication withoutphysical presence, an emphasis on greener technology, i.e., paperlessoffice, cost cutting by optimizing work flow, leverage partnerships byoptimizing cooperation with third parties and security from malicious oraccidental incidents.

The present invention answers these needs and more. The presentinvention can comprise a computer platform with its own operatingsystem, services and applications and most importantly the ability toaccommodate new signing, authentication and signer identificationapplications as they are needed.

The only way to secure the future of signature pads is to avoidpredicting it and instead create a limitless sign anywheresoftware/hardware platform.

Methods, systems and devices that implement the embodiments of variousfeatures of the system will now be described with reference to thedrawings. The drawings and the associated descriptions are provided toillustrate embodiments of the system and not to limit the scope of theinvention. Reference in the specification to “one embodiment” or “anembodiment” is intended to indicate that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least an embodiment of the invention. The appearancesof the phrase “in one embodiment” or “an embodiment” in various placesin the specification are not necessarily all referring to the sameembodiment.

Throughout the drawings, reference numbers are re-used to indicatecorrespondence between referenced elements. In addition, the first digitof each reference number indicates the figure where the element firstappears.

As used in this disclosure, except where the context requires otherwise,the term “comprise” and variations of the term, such as “comprising”,“comprises” and “comprised” are not intended to exclude other additives,components, integers or steps.

In the following description, specific details are given to provide athorough understanding of the embodiments. However, it will beunderstood by one of ordinary skill in the art that the embodiments maybe practiced without these specific details. Well-known circuits,structures and techniques may not be shown in detail in order not toobscure the embodiments. For example, circuits may be shown in blockdiagrams in order not to obscure the embodiments in unnecessary detail.

Also, it is noted that the embodiments may be described as a processthat is depicted as a flowchart, a flow diagram, a structure diagram, ora block diagram. Although a flowchart may describe the operations as asequential process, many of the operations can be performed in parallelor concurrently. In addition, the order of the operations may berearranged. A process is terminated when its operations are completed. Aprocess may correspond to a method, a function, a procedure, asubroutine, a subprogram, etc. When a process corresponds to a function,its termination corresponds to a return of the function to the callingfunction or the main function.

Moreover, a storage may represent one or more devices for storing data,including read-only memory (ROM), random access memory (RAM), magneticdisk storage mediums, optical storage mediums, flash memory devicesand/or other machine readable mediums for storing information.

Furthermore, embodiments may be implemented by hardware, software,firmware, middleware, microcode, or a combination thereof. Whenimplemented in software, firmware, middleware or microcode, the programcode or code segments to perform the necessary tasks may be stored in amachine-readable medium such as a storage medium or other storage(s). Aprocessor may perform the necessary tasks. A code segment may representa procedure, a function, a subprogram, a program, a routine, asubroutine, a module, a software package, a class, or a combination ofinstructions, data structures, or program statements. A code segment maybe coupled to another code segment or a hardware circuit by passingand/or receiving information, data, arguments, parameters, or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted through a suitable means including memorysharing, message passing, token passing, network transmission, etc.

In the following description, certain terminology is used to describecertain features of one or more embodiments of the invention.

The term “vPad” (Virtual Pad) refers to electronic signature pads thatwill be based on a single common platform/architecture as disclosed inthis disclosure.

The term “document” refers to any item that may need to be securelyauthorized, such as, for example, electronic bill payments and legaldocuments among others.

The term “fragmented signing engine” refers to a secure computer systemthat does not contain all the security information necessary tocompletely sign a document.

The term “circle of trust” refers to one or more fragmented signingengines that have established a trustworthy relationship with a user.

Referring now to FIG. 2, there is shown a diagram of a distributedsystem for multi-function secure verifiable signer authentication 200according to one embodiment of the present invention. According to oneembodiment, a mobile device 202 or a computer 204 can be used to accessthe Internet 206 and access web servers 208 and 210. Once the mobiledevice 202 or the computer 204 have entered the site and beenauthenticated to pass through a firewall 212 and access the secureserver 214, the document signing process can begin.

Referring now to FIG. 3, there is shown a chart 300 of the strength ofadmissibility of various signature authentication techniques. Atraditional signing engine (see FIG. 1) performs the three standarddigital signature operations in the same physical hardware on thesigning server. All documents are signed by the “server certificate” andall digital signatures produced are identical. The actual signer'scredentials are ignored and never used. The admissibility of this typeof digital signatures in the court of law is low because people arewitnessing the signing activity instead of being part of the signingprocess. The (1) time, (2) place, (3) hardware used and (4) documentthat was signed is captured, but the signed documents do not contain anyinformation about the actual signer. This is the reason why digitalsignatures that are generated online today are the least trustworthy.

On the opposite end of the chart is a vPad digital signature the hasboth the strongest signature type and the greatest admissibility.

Finally, a word on security. IntegriSign Emcee Mobile provides thehighest level of security for digital signing. As it can be seen in FIG.2, while a signature image or a click-through online digital signatureprovides the least forensic value, a signature produced by a vPadprovides the most forensic value. In other words, in the wide spectrumof signature admissibility in the court of law vPad signatures rank atthe top of the scale. This is because a signer will have a hard timeconvincing a judge that he did not use his own mobile device to createthe signature image and that he did not allow his own private key to beused to create the digital signature.

Referring now to FIG. 4, there is shown a detailed diagram 400 of thesystem of FIG. 2 according to one embodiment. A mobile device 402connects via the Internet 404 to a fragmented signing engine 406 that ispart of the user's circle of trust. The user enrolls the mobile device408 and a key pair is created and stored on the fragmented signingengine 406. The fragmented signing engine 406 generates a pseudo signeddocument that the user selects for signing and embeds a null digitalsignature in the document. After the user has enrolled 408, a signerscertificate is generated using a hash of the document, user'sidentification, such as, for example, a stored digitized copy of theuser's signature, a time and a place 410. In a preferred embodiment, thehash is a twenty byte digest hash. The hash is sent via the Internet 404using a secure protocol to a circle of trust server. The circle of trustserver is in the user's circle of trust and comprises one or moreprivate keys 414 that represent the owner of the mobile device. Thecircle of trust server generates a signer's certificate 412 andtransmits the signer's certificate 412 to the fragmented signing engine406. The fragmented signing engine 406 then replaces the pseudosignature with the authenticated digital signature in the document 416and then transmits the signed, authenticated document to a destinationfor processing.

The digital signatures produced are all different and only one persigner. This type of digital signature binds the document, the time, theplace and the signer credentials in a single encrypted structure, thusproviding the highest level of non-repudiation. The “server certificate”is not used as in the past (see FIG. 1).

A distributed signing engine, according to one embodiment, is providedthat signs documents using “signer certificates”. The digital signaturesof the signer certificates produced are all different as they should be,one per signer. This type of digital signature binds the document, thetime, the place and the signer's credentials in a single encryptedstructure, thus providing the highest level of non-repudiation. The“server certificate” is not used.

The distributed engine proposed requires that sensitive information becommunicated between the server and the mobile device. The securityprotocol outlined below is an integral part of the distributed engine.

The protocol in its present form is a preferred but not exclusiveembodiment. The need for secure communications for the distributedengine may be satisfied by other future variations of this protocol.

Referring now to FIG. 5 there is shown a chart of a protocol method forinitialization 500 of the system of FIG. 2 according to one embodiment.First, a user visits a Web site where an application can be downloadedand installed 502 on a mobile device. A circle of trust server list isalso downloaded comprising {SiteName,URL} pairs for each of the circleof trust servers in the list. Next, the user starts the application 504.Then, a key pair, public and private, are generated and stored 506 in anew secure storage location on the mobile device. The key pair is linkedto the user who is the owner of the device. Next, a temporary uniquehash is generated 508 from the owner's name and a unique deviceidentification that is embedded in the mobile device {OwnerName, UniqueDevice ID}. This unique device identification represents the user.Finally, the application starts and displays an interactive screen tothe user 510.

FIG. 6 is a chart of a protocol method for enrollment 600 in the systemof FIG. 2 according to one embodiment. First a user establishes a clientprofile or has an existing client profile on the site hosting the server602. Next, the user, who is also the owner of the vPad, uses a browserto access and display the vPad enrollment Web page of the site 604.Then, the user can press an “ENROLL” button on the vPad to enroll 606.Optionally, client is asked to enter his email address for use in securecommunications. Next, a unique user reference number (URN) is generatedand displayed on the screen 608. Optionally, the URN can be a single use5 digit number URN that goes from 1-99999 and loops back to 1.Optionally URN is emailed to the user. Then, the vPad application isstarted and the initialization steps (see above) are performed. Next,upon successful initialization of the vPad, the latest ServerList ofparticipating sites is automatically downloaded and/or updatedautomatically from the Web site 610. Then, a splash (start) screen isdisplayed 612. Next, the user is prompted to select a server from theServerList 610. The servers listed in the ServerList 610 are all vPadenabled 614. Then, the user carefully selects the same CustomerName asthe one he visited with the Web browser and types in the URN displayedon the browser screen 616. Next, the user presses the “REGISTER” buttonto register the user's device with the selected server 618. Then, theURL is resolved 620. Next, a server certificate is sent 622. Then, thecertificate sent comprises the URL of the site that hosts the server.The certificate sent must be a third party trusted certificate. Next,the URL is compared against the URL sent 624. Then, the UDID and the URNare concatenated {UDID+URN} and then encrypted with a server public key626 forming an Spub. Next, the Spub{UDID+URN} is sent to the server 628.Then, the sent Spub data is received and decrypted using a serverprivate key and the UDID and the URN are extracted. Preferably, theextracted UDID comprises a first twenty (20) bytes of the received dataand the URN comprises the remaining bytes of the received data. Next,the UDID is stored in a client profile. Then, the received URN iscompared against the generated URN 630. Next, an ACK 632 is sent to themobile device indicating that the previous step has been received. Then,the mobile device sends a client public key to the server 634. Next, theclient public key 636 is stored in the client profile on the server.Then, an ACK indicating that the public key has been stored is sent tothe mobile device 638. Next, a self-signed client certificate associatedto receive UDID and other client profile info is produced 640. Then, aself-signed means is published (i.e., signed) by the site 642. Next, aClientCert is sent to the mobile device 644. Then, the ClientCertassociated to the sent UDID is stored in a local secure storage on themobile device 646. Next, an ACK that the ClientCert step above has beencompleted is sent to the site 648. Finally, the user disconnects 650from the site.

FIG. 7 is a chart of a protocol method for authentication 700 for thesystem of FIG. 2 according to one embodiment. First, the vPad isinitialized. Then, a copy of the latest ServerList of participatingsites is automatically downloaded and/or updated automatically from theWeb site 702. Next, a splash (start) screen is displayed 704. Then, theuser is prompted to select a server from the ServerList of supportedsites. Optionally, all of the listed servers and sites are vPad enabled706. Next, the user selects a CustomerName from the ServerList andpresses a “CONNECT” button 708. Then, the URL of the server is resolved710. Next, the server cert is sent 712. Then, the certificate isverified 720. The certificate must be a third party trusted certificatewhich contains the URL of the site that hosts the server. Next, the URLis compared against the resolved URL 714. Then, a ClientCert isretrieved from a local secure storage 716. Next, the ClientCert is sent718. Then, the ClientCert is verified and a client profile identified bythe ClientCert is retrieved on the server 720. Next, a Challenge isgenerated 722. In a preferred embodiment, the challenge comprises a 20byte random byte array and is encrypted with a client public key foundin the Client profile 722. Then, the challenge is sent 724. Next, thechallenge is decrypted using the private key retrieved from the localsecure storage 726. Then, the challenge and a unique deviceidentification {Challenge+UDID} are concatenated and a hash is generatedfrom the concatenation. Next, the hash with the public server key fromthe server cert is encrypted to produce the response to the challenge728. Then the response to the challenge is sent 730. Next, the responseto the challenge is decrypted using the server private key and theresponse to the challenge is extracted 732. In a preferred embodiment,the response to the challenge comprises the first 20 bytes and the UDIDcomprises the remaining bytes. Then, the response to the challenge isverified against the challenge sent and the received UDID against theone stored in the Client profile 734. If response to the challenge isverified, then an acknowledgement (ACK) is sent 736. Next, a sequence toestablish two way SSL secure channel is initiated 738. Then, an SSL twoway secure channel is established 740. Next, the server prepares to sendsignature image data 742. Then, image data of a user's signature is sentin the clear using the secure SSL channel 744. Finally, the devicedisconnects from the server 746.

Digital signatures were invented in 1976 and the RSA algorithm was firstpublished in 1978. These mathematical inventions are based on the notionof a key pair: a private key and a public key. The private key owned bya signer is used to sign and the public key known to everyone is used toverify. While simple to understand, it is very difficult to make goodpractice. Beginning in 1978 companies started looking for ways tocreate, store and manage these key-pairs in a secure and user friendlymanner. To date no clear solution has been discovered or implemented.

The two opposing forces of security and user friendliness have plaguedthe industry since its inception. Several products have failed in themarket place because Public-private Key Infrastructure (PKI) was tooexpensive and/or too difficult to understand, install and manage.Without PKI there can be no digital signatures and PKI is too expensiveand unusable by non-technical people.

The present invention proposes a new concept called “Circles of Trust”to counter both the high cost and usability problems of PKI. The highcost of PKI comes from the fact that certificates are bought and sold onthe market and prices range from four dollars to thousands of dollarsper certificate annually. Companies like VeriSign® charge for theservice of verifying and asserting the identity of the owner of acertificate. The idea being, that a VeriSign® certificate for example,would be acceptable by anyone and by any company on earth and nobodywould ever doubt this certificate. However, early on people naturallystarted to doubt certificates, and when processes of how owneridentities are checked were placed under the microscope, companies likeVeriSign® and others stopped being the panacea that the industry thoughtthey would be. Reacting to this market revolt, companies that hadalready bought certificates created monstrous hardware and softwareinfrastructures and hired expensive specialists to protect theirinvestment and make PKI work for them. Other companies decided todismantle PKI from their organization too late, after having alreadyspent millions of dollars trying to make PKI work.

The present invention will generate and use private-public key pairs andcertificates. “Circles of trust” was born out of the observation thattrust is a complex human feeling that never travels far. In other words,an individual has a small group of people that he trusts: a mechanic tofix his car, a dentist, a lawyer, a priest etc., usually half a dozen toa dozen people. The individual next to him has his own circle of trustwhich, most often than not, includes different people. The same holdstrue for a university for example. Students go through a rigorousprogram to become a professional and for as long as they stay within thecountry their diploma is recognized automatically. However, if theydecide to immigrate to another country, they sometimes find out to theirsurprise that their diploma is not trusted and often asked to pass testsfor example. The circle of trust for a university is the country inwhich it resides. Trust never travels far.

Initial attempts to use PKI certificates failed because we ignored thisvery strong human need to keep our circles of trust small. As humans, wewere not ready then, and we are not ready now to accept that all sevenbillion of us would be given and use VeriSign® certificates. We knowtoday that a globally acceptable certificate is a Utopia not apracticality.

The present invention provides that each server is in the center of itsown “signing circle of trust” controlling which traditional browsers,devices, mobile devices and other “signing clients” are allowed in thecircle by granting them a certificate (FIG. 8). The certificate, thepublic key of the signing client and information about the signingclient are bundled together and signed by the private key of the server.Both the public key of the signing client and the information about thesigning client are public information. By signing this publicinformation with its private key, the server attests that it has checkedand verified that this public information is correct and that from nowon it is willing to cooperate with this signing client. In practice, theserver does not actually check the owner information. It relies oncustomer authentication systems that have examined the owner and haveprovide a user profile to the server. The certificate generated isalways associated to a particular user profile known to the server. Oncea certificate is issued, it is stored at the server and then sent to thesigning client to be stored there as well. Whenever a signing clientwishes from then on to cooperate with the server, the signing clientneeds to provide this certificate to the server. The certificate is aunique and secure membership token into the circle of trust.

The cost of purchasing certificates is eliminated since each server is acertificate server as well, generating certificates for free. Thesecertificates are mathematically identical and equally secure tocertificates that cost thousands of dollars. The certificates producedby the servers can be identical to VeriSign® certificates. Also, bothsigning clients and servers generate private and public keys for free,on their own, and they do not need to purchase them.

The circle of trust is a closed system between the server and itsmembers, the entire process can be fully automated. The user can log inat a traditional browser PC equipped with an electronic signature pad,such as, for example, an ePad, or a tablet PC among others. Theuser/owner is not aware of the complex exchanges that take place betweentheir client devices and the circle of trust server. Once the devicesare enrolled, i.e., they become members in a circle of trust, PKIliterally disappears from the user lever but continues in thebackground.

Certificates issued by a circle of trust server can control whichsigning clients have access to its circle of trust. If a signing clientwishes to belong to two circles of trust in the present implementationit will have to obtain two certificates one from each circle of trustserver. This inconvenience can be alleviated if the two Emcee serverscould create an inter-trust relation between them that would allow oneto accept the certificates of the other.

FIG. 8 is a diagram representing circles of trust 800 useful for thesystem of FIG. 2. A user can have a first circle of trust 802, a secondcircle of trust 804, a third circle of trust 806, etc. Each circle oftrust 802-806 comprises separate certificate and key pairs for the user.

ADVANTAGES OF THE PRESENT INVENTION

Traditional signing engines require that all the signing activities takeplace in the same hardware. The document to be signed, the certificatesto sign with, the clock to provide the timestamp, and the location info(i.e., hardware info) are all present in the same hardware configurationand there is no need for any data to travel on networks.

The Web changed everything. Obtaining and verifying digital signaturesis no longer what it used to be. “Physical presence” has been replacedby “signer authentication” and “Signature image” has been replaced by a“watermark and some info”.

In this new signing environment a signature touch pad has a new role toplay. It is no longer sufficient to simply capture a good-looking imageof the signer's squiggle. A signing device must provide signercredentials for authentication, secure access to the Web, securetransmission of data, secure local storage, and its own credentials fordevice authentication.

It is envisioned that a pad that is partially a cellular phone,partially a wireless PDA, partially a smartcard, partially an ATMkeypad, partially a magstripe reader, partially a smartcard reader,partially a user token ID, etc. will meet this need. The difficulty isthat such a device must also fit in the palm of a hand, be easy to useand maintain and cost about the same if not less than today's signaturepads.

In addition, a signature pad must become an extension of the signingtools in the future, by providing a significant part of the new signingexperience. A pad equipped with security hardware will become thetrusted credential in the new signing environment. In a way, a pad is inan excellent position to become the signer. Online signing servers onthe Web will trust such pads and they will rely on them to capture andprovide signer ID and signer intent remotely.

One can easily see that this new functionality is not a replacement toexisting features. The signing device of the future must continue tocapture high quality handwritten signatures, must continue to displaycolor images and must continue to measure bio-behavior (e.g. pressure,direction, velocity, etc.).

So a pad will be asked to do more. It will also be asked to change form.Migration from the desktop to the palm of a hand first, and from asingle-function device to a multi-function secure signer ID second, arethe two main market thrusts that will dictate the unavoidable change totoday's pad.

Although the present invention has been discussed in considerable detailwith reference to certain preferred embodiments, other embodiments arepossible. Therefore, the scope of the appended claims should not belimited to the description of preferred embodiments contained in thisdisclosure. All references cited herein are incorporated by reference intheir entirety.

1. A distributed system for multi-function secure verifiable signerauthentication, the system comprising: a) a personal private key; b) amobile device for storing the personal private key, where the mobiledevice further comprises a secure local storage; c) a fragmenteddistributed signing engine communicatively coupled to the mobile device;d) a secure protocol communicatively coupled to both the mobile deviceand the fragmented signing engine; e) a circle of trust certificateserver communicatively coupled to the mobile device; and f) a signercertificate communicatively coupled to the mobile device, the circle oftrust certificate server and the fragmented distributed signing engine.2. The system of claim 1, where the personal private key is a privatekey issued by the circle of trust certificate server.
 3. The system ofclaim 1, where the signer certificate comprises the document, a time, aplace and signer credentials in a single encrypted structure.
 4. Thesystem of claim 1, where the mobile device is configured for securewireless Internet access.
 5. The system of claim 1, where the mobiledevice is selected from the group consisting of a cellular phone, acomputer, a wireless PDA, a smartcard, an ATM keypad, a magstripe readerand a smartcard reader.
 6. The system of claim 1, where the fragmenteddistributed signing engine is configured to hash and prepare a documentfor authenticated digital signing.
 7. The system of claim 1, where themobile device is configured to sign with the personal private key of thesigner and send the resulting digital signature back to the server to beembed into the document.
 8. The system of claim 1, where the protocol isconfigured to securely transmit at least part of a complete securelysigned document to the fragmented distributed signing engine, from thefragmented distributed signing engine or both to and from the fragmenteddistributed signing engine.
 9. The system of claim 1, where the protocolis configured to secure transmit at least part of a complete securelysigned document to the mobile device, from the mobile device or both toand from the mobile device.
 10. The system of claim 1, where protocolmeans for secure transmission between the mobile device and thefragmented distributed signing engine is distributed.
 11. The system ofclaim 1, where the circle of trust certificate comprises a public keyand information about the user.
 12. The system of claim 1, where thesigner certificate is unique to each signer.
 13. The system of claim 12,where the signer certificate is unique to each circle of trustcertificate.
 14. A method for a distributed system for multi-functionsecure verifiable signer authentication, the method comprising the stepsof: a) providing the system of claim 1; b) joining a circle of trust; c)obtaining a personal private key; d) providing a document to be securelysigned from a fragmented distributed signing engine; e) signing theprovided document using the personal private key; f) recombining theprovided document and the personal private key by the fragmented signingengine; and g) transmitting the recombined document to a destination.15. The method of claim 14, where the step of joining further comprisesprotocol means for securely transmitting information between the mobiledevice and the fragmented distributed signing engine.
 16. The method ofclaim 14, where the step of obtaining a personal private key isperformed by the circle of trust server using a user's profileinformation and a unique device identification.
 17. The method of claim16, where the circle of trust server combines the user's profileinformation and the unique device identification into a unique userreference number for a particular circle of trust.
 18. The method ofclaim 17, where the user's profile information, unique deviceidentification and unique user reference number are stored on the circleof trust server for securely verifying the mobile device.
 19. The methodof claim 14, where the step of recombining the provided documentincludes transmitting a challenge and receiving a response from themobile device.
 20. The method of claim 19, where the challenge andresponse use the private key of the device and no server certificates.21. A method for a protocol for a distributed system for multi-functionsecure verifiable signer authentication, the method comprising the stepsof: a) initialization of the mobile device; b) enrolling a mobile deviceto a secure server; and c) authenticating the mobile device to thesecure server.
 22. The method of claim 21, where the step ofinitialization further comprises the steps of: a) acquiring anapplication comprising the protocol; b) starting the application; c)generating a public key and a private key based on PKI technology andthe user's information; d) storing the public key and the private key inthe mobile device; and e) generating a temporary unique hash from theuser's name and a unique device identification.
 23. The method of claim21, where the step of enrolling further comprises the steps of: a)providing a profile to the circle of trust server; b) generating aunique user reference number from the provided information; c)displaying the unique user reference number; d) selecting a circle oftrust server from a displayed list on the mobile device; e) entering theunique user reference number; f) registering the mobile device with thecircle of trust server; g) verifying the signer certificate; h)combining the unique user reference number and the unique deviceidentification and the public key; i) transmitting data bidirectionallywith the circle of trust server using the combination of step h); j)decrypting at the circle of trust server the data; k) storing on thecircle of trust server the unique user reference number and the uniquedevice identification in the profile; l) producing a signer certificate;m) transmitting the signer certificate to the mobile device; and n)storing the signer certificate in the local secure storage on the mobiledevice
 24. The method of claim 23, where the unique user referencenumber is transmitted to the user by email.
 25. The method of claim 21,where the step of authenticating further comprises the steps of: a)executing an application comprising the protocol; b) downloading acircle of trust server list; c) displaying the list on the mobiledevice; d) selecting a circle of trust server from the displayed list;e) connecting to the selected circle of trust server; f) verifying asigner certificate stored in the mobile device; g) retrieving theprofile associated with the signer certificate; h) generating achallenge to the mobile device using the public key stored in theprofile; i) transmitting the challenge to the mobile device; j)decrypting on the mobile device the challenge using the private keystored in the local secure storage; k) combining the challenge and theunique device identification; l) generating a hash from the combinationin step k); m) encrypting the hash with the public key received from thecircle of trust server to produce a response to the challenge; n) sendthe response to the circle of trust server; o) decrypting the responseusing a server private key to extract the response and the unique deviceidentification; P) verifying the challenge and the response; q)providing a secure channel between the mobile device and the circle oftrust server if the challenge and response are verified; and r)transmitting signature data.
 26. A method for obtaining an electronicsignature comprising the steps of: a) receiving at a document server arequest for a document to be signed; b) providing the requested documentfor receipt by a mobile device; and c) receiving the signed documentfrom the mobile device with a signer certificate, the signer certificatebeing unique for the mobile device and the document, the certificatehaving been provided to the mobile device by an authentication serverphysically separate from the document server.
 27. The method of claim26, where the second server is remote from the first server.
 28. Amethod of authenticating an electronic signature for a documentcomprising the steps of: a) storing personal private key for use with aunique mobile device and personal information associated with a user ofthe mobile device; b) receiving a request to certify the user at anauthentication server, the request including the personal private key, aunique identifier for the mobile device, and information relating to thedocument, the information relating to the document and the documenthaving been provided by a document server separate from theauthentication server; and c) providing to the mobile device a signercertificate for the certified user, the signer certificate being uniquefor the mobile device and the document, the signer certificate beingreadable by the document server.